Data in business applications with modern object oriented design are typically in the format of one or more business entities and current state information such as a point-of-sales (POS) application and an accounting application, for example. Both of these applications have the business object concepts of items, transactions, customers, etc. Eventually, these application objects need to be synchronized. With a greater need for directly synchronizing the data between business applications, the methods for synchronizing these data become more interesting. The core of such methods is to decide the problem model and come up with an algorithm to handle such business entity synchronization.
Business entities can be changed and it is the changes that need to be synchronized between the business applications once the entities in different systems are matched up. Changes can be categorized into one of three types according to the affect on the business entity. With respect to “snap-shot” changes, only after-change results matter and are stored (e.g., a customer address change). Characteristics of “delta” changes are that both the before and after change information matters and both are stored. However, the change process itself virtually does not take any time. This resembles observing a database transaction from the outside; either there is no result or there is the final result of the transaction (e.g., an inventory asset value change resulting from an immediately settled cash sale transaction on an inventory item). “Long-running-process” changes can run hours, days, or even months. Thus, a synchronization process can occur at any stage of the process (e.g., an approval process for a special discount to a favored customer which may take several days and involve multiple people in an organization).
Depending on the business application domain and purpose, the application can include one or more of the above three change processes. Conventionally, these changes are imposed in the business system by a designated master among two or more business applications. This can be a problem where there may be an object inconsistency, since the master may not have the latest information, yet be declared the winner. Accordingly, when businesses grow, the number of business applications can grow, thereby creating objects at different locations that must be synchronized not only from the front office applications to back office applications, but also from back office applications to the front office applications.